View AN1152_2278833.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

AN1152/1100 1/16 AN1152 application note optimizing the usage of the st92f120 eeprom by micro division applications 1 programming eeprom this application note document describes the on-chip emulated eeprom of the st92f120 paying special attention to intelligent data management aspects, to optimize the cycling, in order to maximise the endurance. 1.1 introduction on this product, up to 1 kbyte of on-chip eeprom is available. it consists of a hardware em- ulation of eeprom functionality implemented through a physical flash memory concept and circuitry. one of the main differences from the user point of view between eeprom and flash is the minimum erasable set of data. typically, eeprom allows the user to modify single byte loca- tions: a data stored at a specific address can be updated individually. in contrast, a flash memory can be updated only by sectors (sector size is defined by architectural and technolog- ical constraints). a second aspect, which does not impact the user application, but is not less important, is the physical basic memory cell size: a flash basic cell is typically three/four times smaller than an eeprom cell. this can have big impact on the product die size, with ob- vious effects on its price; consequently a bigger memory cut can be implemented using a flash concept in place of eeprom without impacting die size. a specific hardware solution has been implemented in order to create an eeprom using a flash: a compromise between real eeprom characteristics and flash specifics has been adopted. the eeprom available on the st92f120 can be updated only at page level (each page corresponds to 16 bytes); besides, since the updating of the flash content requires a sector erasing phase followed by a writing phase, a redundant physical memory space is used to implement a typical eeprom data updating cycle (which usually requires a local and faster erasing phase on the single byte: this phase is hidden to the user). two flash memory sectors of 4 kbytes each are used to implement 1 kbytes of emulated eeprom. the emulated eeprom can be directly addressed by the user as a contiguous 1 kbyte area from 220000h to 2203ffh, without considering the internal mechanism which uses the two 4 kbyte flash sectors. 1
2/16 optimizing the usage of the st92f120 eeprom an important parameter to be aware of when using eeprom emulation through a flash, is the endurance, defined as maximum number of updating cycles. a real eeprom guarantees typically 100 kcycles for each byte; since the flash is erased and written by sectors, it is not possible to guarantee the number of cycle for each byte. a flash endurance parameter is also provided, but it refers to sector based updating. a brief explanation of the emulation mechanism is given here in order to provide the user with some guidelines for efficient software application development. by smartly managing the storage addresses of variables in eeprom according to their updating frequency, it is pos- sible to obtain a higher number for cycling endurance at byte level, with the same number of erase cycles for the corresponding flash sectors. 1.2 hardware eeprom emulation both the emulated eeprom (1 kbytes) and the two physical flash sectors e0 and e1 (4 kbytes each) are mapped on page 22h. each sector is divided in 4 blocks of 1 kbytes each (size of eeprom to emulate). again, each block is composed of 64 pages of 16 bytes each: the page is the minimum set of data that can be updated in the emulated eeprom. of course, the user can also update less than 16 bytes, but internally the algorithm always performs the full page update (copying the unchanged data). figure 1. shows a schematic representation of the physical flash organization for the eeprom emulation sectors e0 and e1. a 16-byte ram buffer (page size) is used for page programming operations. the emulated 1 kbyte eeprom is composed of 64 pages: page 0 physically corresponds to one of the eight page 0s inside the two sectors (one for each block); the same for page 1, page 2 and so on. the correspondence is defined through a set of block pointers (one for each 16-byte page); another dedicated pointer selects the active sector (one common pointer for all the pages). a simplified diagram showing an example of the user eeprom space def- inition is given in figure 2., at any time, the single page of user eeprom is determined through the block selector (one independent block selector for each page, correspondent to a block pointer); besides, a multipolar switch is used to define the active sector (a common switch for all the pages, corresponding to the sector pointer). the pointer values are defined by the emulation mechanism described in the next paragraph. 2
3/16 optimizing the usage of the st92f120 eeprom figure 1. mapping of emulated eeprom and physical flash sectors e0 and e1 228fffh flash sector e0 228000h 228400h 228800h 228c00h 22cfffh 22c000h 22c400h 22c800h 22cc00h block 0 1 kbyte 220000h 2203ffh emulated eeprom 2283ffh 2287ffh 228bffh 22c3ffh 22c7ffh 22cbffh page 0 page 1 16 bytes 16 bytes page 62 16 bytes page 63 16 bytes block 1 1 kbyte page 0 page 1 16 bytes 16 bytes page 62 16 bytes page 63 16 bytes block 2 1 kbyte page 0 page 1 16 bytes 16 bytes page 62 16 bytes page 63 16 bytes block 3 1 kbyte page 0 page 1 16 bytes 16 bytes page 62 16 bytes page 63 16 bytes flash sector e1 block 0 1 kbyte page 0 page 1 16 bytes 16 bytes page 62 16 bytes page 63 16 bytes block 1 1 kbyte page 0 page 1 16 bytes 16 bytes page 62 16 bytes page 63 16 bytes block 2 1 kbyte page 0 page 1 16 bytes 16 bytes page 62 16 bytes page 63 16 bytes block 3 1 kbyte page 0 page 1 16 bytes 16 bytes page 62 16 bytes page 63 16 bytes 1 kbyte page 0 page 1 16 bytes 16 bytes page 62 16 bytes page 63 16 bytes ram buffer 16 bytes
4/16 optimizing the usage of the st92f120 eeprom 1.3 emulation algorithm when no data has been stored in user eeprom yet, the pointers are set to address all the pages of the first block (block 0) of sector e0. in this way, the first data programming for each page is physically done on block 0 of sector e0. first data programming includes also initial- ization and test routines run before the product shipment: this means that when the final user starts working with the device, the pointer configuration can be different; anyway it does not have any impact on the software application in addressing the user eeprom (it is a trans- parent mechanism), and it is assumed as hypothesis for the treatment. figure 2. user eeprom definition sector e0 sector e1 emulated eeprom page x page x page x page x block 0 block 1 block 2 block 3 block 0 block 1 bl ock 2 block 3 3 2 1 0 page x page x page x page x page y page y page y page y 3 2 1 0 page y page y page y page y : : : : : : : : : : : : : : : : : : page y page x page x block selector page y block selector sector selector ::
5/16 optimizing the usage of the st92f120 eeprom each time the user updates the same page content, the block selector pointer is incremented (automatic internal operation); since the data are physically stored in a flash sector, when a page update occurs, it is not possible to erase the whole sector: so the updated page is written on the following block of the same sector (on the corresponding page). this operation is re- peated each time the same page is updated (this is not visible to the user, who always ad- dresses the same data location). assuming (for simplicity) a starting configuration with all pages physically mapped on block 0 of sector e0, each page can be updated up to four times without switching the sector (moving from block 0 to block 3). when a new page update operation is launched (the fifth update of the same page), a sector switch also occurs: sector e1 and block 0 are selected, and the new data are stored in these locations. simultaneously, a sector erase operation is started on sector e0, and it is divided in four phases: during the next four page update instructions (whatever the involved pages are, either four different pages or four times the same one), flash sector e0 is automatically and com- pletely erased, allowing a new sector switching from e1 to e0 again. figure 3., figure 4., figure 5. and figure 6. show the evolution of the internal situation when the same page is continuously updated. from this sequence of drawings, it is clear that a sector erasing is carried out in a minimum of 4 page update operations on the user eeprom: erasing of both the sectors requires 8 update instructions. it is a minimum since a cycle of 8 consecutive update operations of the same user page is considered. normally, the user up- dates randomly the data in the pages, increasing the number of average page update opera- tions for each sector erasing.
6/16 optimizing the usage of the st92f120 eeprom 1.4 endurance computation one of the most important characteristics of a non-volatile memory is the number of times each byte can be updated without degrading data retention capability. as already explained, the emulated eeprom implemented through a flash memory has some constraints which can have an impact on the maximum cycling. the following gives some examples on how to compute the maximum number of updates, referring to different data storage characteristics. this takes into account the endurance specification guaranteed for the st92f120 eeprom: 100 kcycles/sector. this means that, if the data are properly managed, the byte endurance can be comparable with that of a standard eeprom. it must be clear anyway that 100 kcycles are guaranteed on a sector base (each sector can be erased up to 100000 times): this leads to having a greater number of cycles on each block (up to 8 times, since there are 8 blocks when both sectors are considered). this will be more clear during the examples presentation, where the 100000 erasing phases are considered for the sectors. 1.4.1 regular updating of all the variables this case represents the ideal way to manage the emulated eeprom to get the maximum number of cycles/byte. it is reported purely as an example, since it is really an untypical flow for eeprom data management. it consists of the following operative hypotheses: n each time that a byte variable is updated, all 16 variables stored in the same page are updated (it corresponds to updating 16 variables in one shot). n a single page is not updated before all 64 pages are also updated; the order it is not important: it is mandatory that all 64 pages are updated before repeating the operation on the first updated page. n in this way, a complete block switching is performed with a total of 1024 updated bytes: 64 pages x 16 bytes/page = 1024 bytes n assuming that for one full erase of all blocks, 8 updating operations are required, and that an endurance of 100 kcycles/sector is guaranteed, then the maximum global cycling for each byte is: 8 x 100 kcycles = 800 kcycles
7/16 optimizing the usage of the st92f120 eeprom 1.4.2 continuous updating of the same variable in contrast to the previous one, this is an extreme case, which represents the worst way to manage the data in the eeprom. it consists of the following operative hypotheses: n the same byte variable is continuously updated, repeating the operations the maximum number of allowed cycles. n the maximum number of cycles would correspond to 800 kcycles, if only one variable were updated (see previous example): practically, all possible cycles are used for the same variable, but nothing else can be cycled. n assuming this operation is repeated for each byte and the number of variables is 1024 (1 kbyte of user eeprom), the maximum number of cycles for each byte is: 800 kcycles: 1024 = 781 cycles 1.4.3 updating a few variables this is one of the most common situations in eeprom data management. it is the case in which only a subset of bytes of the available eeprom space is frequently updated. it is really important to provide the user with guidelines on how to distribute the variables inside the memory space in order to optimize the effective number of cycles for each of the frequently updated variables. in the following, three separate examples are reported in order to give an idea of how to proceed in defining application software constraints. 1.4.3.1 case a the first specific case is represented by: C 64 frequently updated byte variables C 960 fixed byte variables (never updated) the following operative hypotheses are considered: n each one of the 64 variables is stored in a different page (one per page over all 64 pages). n each of the 64 variables is updated with the same probability. ideally (or statistically), after a variable update operation has been performed, the same variable is not modified again before all the other 63 are also updated. n the updating of the 64 variables can occur in any order. n in this way, each internal block is filled up before switching to the next; this means that a block switching takes 64 update cycles (1 for each variable). n since a full erase takes 8 block switching operations, this produces 8 updates/byte for each erasing cycle; guaranteeing 100 kcycles/sector, each of the 64 variables can reach: 8 x 100 kcycles = 800 kcycles
8/16 optimizing the usage of the st92f120 eeprom this example shows the best way to use memory space for storing variables. this is valid when the number of frequently-updated variables is from 1 to 64, with no change to the final maximum number of cycles for each variable. in the next example the effect of less frequently updated variables is shown: again, a statistical computation of the impact on the maximum number of cycling for the most frequently updated variables is given. 1.4.3.2 case b this second and more generic example is represented by: C 64 frequently updated byte variables C 960 rarely updated byte variables the following operative hypotheses are considered: n the 64 variables are stored one in each page. n each of the 64 frequently updated variables is changed with the same probability. ideally (or statistically), after a variable updating operation has been performed, the same variable is not modified again before all the other 63 are also updated. n the rarely updated variables are assumed to be changed with a rate equal to 1/960 of the rate of change of the frequently updated variables (value assumed for simplicity). n one of the 960 rarely updated variables is changed each time all the 64 frequently updated variables are changed. n each of the 960 rarely updated variables is changed with the same probability. ideally (or statistically), after a variable update operation has been performed, the same variable is not modified again before all the other 959 are updated also. n to complete at least one change of all variables (rarely and frequently updated) it takes: 960 x (64 + 1) = 62400 variable updates n to understand this refer to the flow below as an example, where variables fx(t) and ry(t) represent the frequent and rare variable update operations respectively ( x varying from 1 to 64, y from 1 to 960, where t is the number of update occurrences for the considered variable).
9/16 optimizing the usage of the st92f120 eeprom n taking into account now that a block switching occurs every 64 variable update operations (on average, considering this specific hypothesis of the described variable updating flow), and again that a full erase occurs each 8 block switching, the number of erase phases results: (62400 : 64) : 8 = 122 erase phases n the relationship with the frequently updated variables is simply obtained; during this number of erasing phases the 64 variables are updated 960 times each, so: 960 : 122 = 7.8 update/byte (for each erase) n in conclusion, guaranteeing 100 kcycles for each sector, it is simple to obtain the maximum number of cycles for the frequently updated variables: 7.8 x 100 kcycles = 780 kcycles n repeating the reasoning for the rarely updated variables it can be derived that one variable is updated every 122 erasing phases; it directly gives the maximum number of cycles: (1 : 122) x 100 kcycles = 820 cycles summarizing the results obtained from cases a and b, the effect on the frequently updated variables of other rare variable updating events is almost negligible. update # updated variables 1 2 : 64 65 f1(1) f2(1) : f64(1) r1(1) 66 67 : 129 130 f1(2) f2(2) : f64(2) r2(1) 131 132 : : f1(3) f2(3) : : : : 62399 62400 : : f64(960) r960(1)
10/16 optimizing the usage of the st92f120 eeprom 1.4.4 case c this third example gives the cycling computation when the few frequently updated variables are randomly changed, without any constraints in the flow (as hypothesized in the previous cases). the following definition are used: nf = number of frequently updated variables nr = number of rarely updated variables pf = probability of frequently updated variables pr = probability of rarely updated variables cf = cycles of each frequently updated variable cr = cycles of each rarely updated variable firstly, it must be said that: pf + pr = 1 considering the maximum 100 kcycles on the sectors, corresponding to 800 kcycles at block level, the relationship which gives the maximum cycles for each frequently updated variable is simply: cf = (800 kcycles x pf) : nf similarly, for the rarely updated variables: cr = (800 kcycles x pr) : nr the variables are supposed to be randomly distributed inside the eeprom space; neverthe- less it is still suggested to place frequently updated variables in different pages: in this way, the maximum number of cycles can be significantly improved, since it is unlikely that a real full random flow is adopted (full random is considered the case in which the same variable is up- dated consequently for all the maximum number of allowed cycles). table 1 presents the computation for some cases. the user can easily deduce different appli- cation configurations.
11/16 optimizing the usage of the st92f120 eeprom 1.5 conclusion this document provides the user with a methodology for using emulated eeprom. it highlights that the number of cycles for each byte can be significantly high, and comparable with the normal eeprom characteristics. this is always true, although the examples shown are simplified and consider ideal hypotheses. the large size of the emulated eeprom space (1 kbyte) should give the user enough flexi- bility for application purposes, in which a set of variables must be updated with high frequency, while for other variables the rate of change is significantly lower. table 1. randomly updated variables nf nr pf pr pr / pf cf (cycles) cr (cycles) 8 1016 100/101 1/101 1/100 99.000 8 8 1016 10/11 1/11 1/10 90.900 72 8 200 100/101 1/101 1/100 99.000 40 8 200 10/11 1/11 1/10 90.900 364 64 960 100/101 1/101 1/100 12.380 8 64 960 10/11 1/11 1/10 11.360 75 64 200 100/101 1/101 1/100 12.380 40 64 200 10/11 1/11 1/10 11.360 364 1024 - 1 - - 781 -
12/16 optimizing the usage of the st92f120 eeprom figure 3. eeprom data updating - phases 1 and 2 sect or e0 sect or e1 emulated eeprom dat a a xx xx xx data a block 0 block 1 block 2 block 3 block 0 block 1 block 2 block 3 3 2 1 0 xx xx xx xx sect or e0 sect or e1 emulated eeprom dat a b xx xx data b data a block 0 block 1 block 2 block 3 block 0 block 1 block 2 block 3 3 2 1 0 xx xx xx xx phase 1 data a storing in page p phase 2 data b storing in page p page p block selector sector selector page p block selector sector selector
13/16 optimizing the usage of the st92f120 eeprom figure 4. eeprom data updating - phases 3 and 4 sect or e0 sect or e1 emulated eeprom data c xx data c data b data a block 0 block 1 block 2 block 3 block 0 block 1 block 2 block 3 3 2 1 0 xx xx xx xx sect or e0 sect or e1 emulated eeprom data d data d data c data b data a block 0 block 1 block 2 block 3 block 0 block 1 block 2 block 3 3 2 1 0 xx xx xx xx phase 3 data c storing in page p phase 4 data d storing in page p page p block selector sector selector page p block selector sector selector
14/16 optimizing the usage of the st92f120 eeprom figure 5. eeprom data updating - phases 5 and 6 sect or e0 sect or e1 emulated eeprom dat a e xx xx xx xx block 0 block 1 block 2 block 3 block 0 block 1 block 2 block 3 3 2 1 0 xx xx xx data e sect or e0 sect or e1 emulated eeprom data f xx xx xx xx block 0 block 1 block 2 block 3 block 0 block 1 block 2 block 3 3 2 1 0 xx xx data f data e phase 5 data e storing in page p sector e0 erase phase 1 phase 6 data e storing in page p sector e0 erase phase 2 1 2 page p block selector sector selector page p block selector sector selector
15/16 optimizing the usage of the st92f120 eeprom figure 6. eeprom data updating - phases 7 and 8 sect or e0 sect or e1 emulated eeprom data g xx xx xx xx block 0 block 1 block 2 block 3 block 0 block 1 block 2 block 3 3 2 1 0 xx data g data f data e sect or e0 sect or e1 emulated eeprom data h xx xx xx xx block 0 block 1 block 2 block 3 block 0 block 1 block 2 block 3 3 2 1 0 data h data g data f data e phase 7 data g storing in page p sector e0 erase phase 3 phase 8 data h storing in page p sector e0 erase phase 4 3 4 (completed) page p block selector sector selector page p block selector sector selector
16/16 optimizing the usage of the st92f120 eeprom the present note which is for guidance only aims at providing customers with information regarding their products in order for them to save time. as a result, stmicroelectronics shall not be held liable for any direct, indirect or consequential damages with respect to any claims arising from the content of such a note and/or the use made by customers of the information contained herein in connexion with their products. information furnished is believed to be accurate and reliable. however, stmicroelectronics assumes no responsibility for the co nsequences of use of such information nor for any infringement of patents or other rights of third parties which may result from its use. no license is granted by implication or otherwise under any patent or patent rights of stmicroelectronics. specifications mentioned in this publicati on are subject to change without notice. this publication supersedes and replaces all information previously supplied. stmicroelectronics prod ucts are not authorized for use as critical components in life support devices or systems without the express written approval of stmicroele ctronics. the st logo is a registered trademark of stmicroelectronics ? 2000 stmicroelectronics - all rights reserved. purchase of i 2 c components by stmicroelectronics conveys a license under the philips i 2 c patent. rights to use these components in an i 2 c system is granted provided that the system conforms to the i 2 c standard specification as defined by philips. stmicroelectronics group of companies australia - brazil - china - finland - france - germany - hong kong - india - italy - japan - malaysia - malta - morocco - sin gapore - spain sweden - switzerland - united kingdom - u.s.a. http://www.st.com

▲Up To Search▲

Price & Availability of AN1152

	To Download AN1152 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .